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PREFACE 


Software  has  critical  cost  and  performance  impacts  on  weapon  system 
acquisition.  The  reemphasis  on  using  appropriate  contract  types  and  recent 
release  of  the  Federal  Acquisition  Regulation  offer  an  opportune  time  to 
address  a  concern  that  "software  acquisitions  and  contract  type  tare!  often 
mismatched”.  This  staff  analysis  project  determines  the  appropriate  pricing 
arrangement,  as  described  in  the  Federal  Acquisition  Regulation  (FAR),  for 
operational  weapon  system  software. 

The  approach  to  the  problem  is:  determine  pricing  arrangement  uses  and 
limitations;  determine  character i sti cs  of  procurement,  acquisition  and  soft¬ 
ware  development  that  affect  pricing  arrangement;  and  select  the  appropriate 
pricing  arrangement  using  FAR  criteria.  This  project  is  sponsored  by  the 
Ballistic  Missile  Office  (BMO).  Specific  BMO  program  examples  that  support 
study  findings  are  in  appendices. 
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the  project  advisor  which  made  the  project  and  this  report  better;  and  Majors 
Buddy  B.  Wood  and  Sherry  D.  Sims  for  their  technical  review  and  comment. 
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setts  as  an  assistant  to  staff  scientists  under  AFIT's  Education  With  Industry 
program.  Following  his  assignment  at  Draper,  Major  Spatola  spent  five  years  at 
the  Ballistic  Missile  Office  (BMO),  Norton  AFB,  California.  At  BMO,  Major 
Spatola  was  the  Chief,  MX  Software  Development  Branch.  He  was  also  the  Minute- 
man  command  and  control  software  manager  during  its  last  program  updates.  As 
the  computer  resources  focal  point  at  BMO,  Major  Spatola  received  a  Certifi¬ 
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EXECUTIVE  SUMMARY 


insights  into  tomorrow ” 


Part  of  our  College  mission  is  distribution  of  the 
students’  problem  solving  products  to  DoD 
sponsors  and  other  interested  agencies  to 
enhance  insight  into  contemporary,  defense 
related  issues.  While  the  College  has  accepted  this 
product  as  meeting  academic  requirements  for 
graduation,  the  views  and  opinions  expressed  or 
implied  are  solely  those  of  the  author  and  should 
not  be  construed  as  carrying  official  sanction. 


REPORT  NUMBER  85-2560 
AUTHOR(S)  MAJOR  MICHAEL  A.  SPATOLA,  USAF 

TITLE  CONTRACTING  FOR  WEAPON  SYSTEM  SOFTWARE:  THE  PRICING  ARRANGEMENT 

I.  PyCROsei  To  determine  the  appropriate  contract  pricing  arrangement,  as 
described  in  the  Federal  Acquisition  Regulation  (FAR),  For  the  development  of 
operational  software  during  weapon  system  acquisition. 

II.  Problem!  With  an  increased  emphasis  on  using  contract  types  that  are 
appropriate  for  the  specific  acquisition  and  the  recent  release  of  the  new 
Federal  Acquisition  Regulations,  it  is  necessary  to  correct  what  some  studies 
refer  to  as  a  "mismatch  between  software  acquisitions  and  contracts". 

III.  Data;.  The  FAR  and  laws  enacted  by  Congress  regulate  the  federal  procure¬ 
ment  system.  The  FAR  describes  applications  and  limitations  for  contracts.  The 
Defense  System  Acquisition  Review  Council  < DS ARC >  procedures  and  federal 
budget  process  influence  system  acquisition.  Department  of  Defense  (DoD) 
directives  and  Air  Force  regulations  govern  both  system  acquisition  and  soft¬ 
ware  development.  Data  for  this  project  include  directives,  regulations,  and 
analyses  of  procurement,  system  acquisition,  and  software  development. 

IV.  Conclusions!  Weapon  system  software  development  has  the  following  charac¬ 
teristics:  changing  requirements,  inadequate  cost  estimates,  and  unknown 
risks.  As  a  result,  either  a  cost-plus-fixed-fee  (CPFF)  or  cost-plus-award-fee 
(CPAF)  contract  is  an  appropriate  pricing  arrangement. 


PRCJEC  •  iNin'UyUU  i  iC N 

t  Dr  ae-  depot.-  undersecretary  of  Defense  F r a n l  Car  i  <u  c  i  :  e e m c n a c  :  : e c  t  h 
"<  to  "employ  contract  types  that  are  appropriate,  considering  . : .  th 
.  an  q  circumstances  involved  in  a  specific  acquisition"  '33:-  i.  •  r,  i 
3Si  s  is  especially  important  for  software  development  contracts,  r,c 
because  of  tne  large  Department  of  Defense  (DoS'  software  investment,  re 
because  "software  acquisition  an  c  contract  type  tare]  often  si:  sr  at  tfed 
;8  •  .  This  staff  analysis  project  determines  what  contra:*  pricing  arrange 
as  described  in  the  Federal  Acquisition  Regulations  ■  F Afi ■  ,  is  a p ?r o sr  t 
Ter  the  development  of  operational  software  during  weapon  s  y.-tei  a  cg-..:si 


r  r  i  s  first  chapter  introduces  tne  software  problem  and  analysis  app-cech 
nap  ter  Two  describes  the  procurement,  acquisition,  ana  budget  processes  i 
etaii  and  their  effects  on  pricing  arrangement,  while  unapter  Three  is  a 
nalvsis  of  software  development  for  the  “facts  ara  circumstances  .  .  .  m 
pacific  acquisition".  The  software  pricing  arrangement  selection  is  ir,  Chao 
er  Four.  Chapter  Five  presents  final  findings  and  conclusions  with  recomoen 
at i one  for  further  study  in  Chapter  Six. 

This  chapter  describes  the  staff  anal, sis  project  by  first  ciscussir-q  tn 
rowing  importance  of  software  in  systems  acquisition  and  "ome  software  p"-r 
at-:.  It  then  highlights  processes  that  af  *ec  t  contracting  *  or  software:  t ; 
r o curement  process,  the  acquisition  process,  ana  the  budget  process.  Finally 
chapter  describes  the  analysis  approach  for  tne  reject. 


t  a  C  f '  ■  R  y  t:  N  D 

l  r.C'  easing  interest  ana  denote  within  Congress  are  wesson  :  / ;  t  e 

.mans  such  as  tne  F-15  and  F-l  &  a;  craft,  ana  tie  small  inter  cent  i er, 

•  1  •.  s  1 1  c  Missile-  t  ICBMt  ana  Peacekeeper  missile  systems.  Hi  ston  ca.  ca¬ 
ms,  difficulties  with  production  schedules,  and  inadequate  foil "w- o 
t  are  major  concerns  that  affect  program  cost  «  23:  t>2  •  .  They  are  a'.s 

acquisition  goals  that  the  Department  of  Defense  :DoD>  and  Congres 

»  :  62  j  .  Regardless  of  tne  weapon  s.stea,  any  accui i >  1 1 on  include 

•.  '  e  development.  Software  is  new  a  critical  performance  and  cost  e  J  erne- 
ipon  system  acquisition. 

1  .t. p or  tance 


reason  for  the  critical  performance  ana  cost  ,  mp  act  c  *' 
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r  ap  i  d  advances  ir,  computer  technology.  Rapid  advances  in  technology  mean 
wide-spread  use  of  computers  and  mi croprocessors.  Embedded  computers  (comout- 
ers  that  are  an  integral  part  oh  a  larger  system)  in  the  Department  oh  Defense 
will  increase  hrom  less  than  10,080  in  t980  to  over  250,000  by  the  end  oh  the 
decade  (13:48).  The  numbers  alone  illustrate  the  expanded  use  oh  computers 
'and  sohtwarei  ir  deher.se  applications.  Increasing  software  applications  mean 
a  greater  sohtware  cost  impact. 


Sohtware  costs  in  a  computer  system  development  now  exceed  hardware  coses 
(21:1:  5:"?4).  The  growth  in  sohtware  costs  relative  to  hardware  costs,  shown 
in  figure  1,  is  due  to  decreasing  hardware  costs  and  an  increasing  reliance  or 
software  to  perform  system  functions.  Because  of  that  reliance,  some  estimates 
are  that  software  development  is  55-70*'.  ot  the  acquisition  costs  for  major  Air 
Force  weapon  systems  (38:19). 


c  i  qure  !.  HerOware/boftware  Cost  Relationship 


Besides  Air  Fc-rce  acquisition  costs,  software  is  now  a  major  part  oh  the 
i  Oudqet.  The  BoD  software  investment  oh  $3  billion  in  1974  will  grow  to  $24 
lion  in  ;v94  1 9 : 10;  13:48).  This  rising  cost  oh  sohtware  development  m- 
des  significant  costs  to  maintain  sohtware.  "The  cost  oh  maintaining  soft- 
e  is  estimated  to  account  her  about  75  percent  o£  software  11  if e-cvcl el 
t:  '  *,  t> :  2  0 ;  .  in  te-ms  Gf  either  cost  or  perf  oraiar.ee ,  software  is  an  lmpor- 
.  -  cart  r  *  ,i  weapon  system.  Cost  and  performance  are  also  software  problems. 


1 •  •.  « •;  5  t;roo  ;  e m s 

Si  an  j  i  leant  problems  cortinue  to  plaque  software.  While  new  :  e  *.  r  ■  -  .  ■ 
ease  the  situation.  "software  overruns  still  occur,  schedules  still  si  1  o 
software  products  still  fall  snort  of  their  goals"  (5:73).  Studies  a  a  i  r  s 
those  problems  list  such  factors  as  incomplete  requirements,  poor  design, 
c)  standards,  and  insufficient  testing  <5: 73-74) .  hut  othe-  studies 
" :  •••sufficient  management  discipline"  (9:  17) .  Still  other  s  add  adt. 
acquisition  planning*  and  a  mismatch  between  "software  acquisition  am 
t-jcc  type"  to  the  list  ••  I  3 :  t  S  >  -  With  the  reeaphasxs  on  using  appript 
pricing  arr angemenis  are  the  recent  FAR  release,  it  is  neces.ar,  to  cor 


SrSIEK  DEVELOPMENT  PROCESSES 

..  c  c  e  r  m  i  r  i  n  g  an  appropriate  contract  strategy,  spsi_i*icailv  the  ^  *  i  - 1  n  u 
: - •anqement  to  stimulate  contractor  performance,  requires  considering  the 
p  '  o  c  u  r  e  men t ,  acquisition,  and  budget  processes.  The  procurement  ana  acquisi¬ 
tion  processes  make  up  key  interrelated  parts  of  the  system  development  pro¬ 
cess.  The  budgeting  process  adds  additional  constraints  and  considerations. 
Earh  impacts  the  suitability  of  a  particular  contract  type. 

Procurement  Process 

highly  specialized  and  complex  contract  law  regulates  bc.err.ment  pror  ....re¬ 
sents  and  pricing  arrangements.  Agencies  of  the  Government  must  procure  sup¬ 
plies  and  services  in  accordance  with  numerous  laws,  regulations,  Directives, 
an:  policies.  The  recently  released  Federal  Acquisition  Regulation,  whose 
injev  alone  requires  34  pages,  contains  many  of  those  requirements. 


Government  agencies  must  apply  the  new  FAR  as  well  as  procurement  poi.cv 
:ui dance  to  each  procurement  and  every  contract.  Former  Deputy  Undersecret ar , 
of  Defense  Frank  Carlucci  reemphasised  the  policy  to  "employ  contract  types 
that  a-?  appropriate.  considering  ail  the  facts  and  circumstances  involved  in 
specific  ucqui  si  1 1  on11  1 33  5  — )  -  Government  agencies  must  now  apply  that 

within  FAR  constraints.  Among  the  FAR  constraints  are  those  that  de- 
-,:-ir.e  both  the  application  and  limitations  of  contract  types  (pricing  ar¬ 


il  n  Process 


!  o  e  framework  for  control  of  the  acquisition  process  is  the  De terse 
stems  Acquisition  Review  Council  (DSARC).  In  May  19&9,  the  DSARC  established 
a  w  e  a  o  :•  n  system  acquisition  concept  of  decentralized  management  with  cei  f '  m 
.  cntrol  of  i  ey  development  decisions  <22:1!.  Although  there  have  ret' 
procedural  changes  in  this  approach .  the  DSARC  review  process  for  s  .etc  n 
acquisition  is  not  substantially  different  than  it  was  in  1 9 & R .  The  tc 
a  c  q  :  i  s  i  1 1  o  n  phases  (concept  exploration.  demons t r a 1 1 on / va 1 i d a t *  on ,  full  'Sidi  : 
d  £  .  el opment .  and  producti on  cepl oyment )  have  key  decision  points  or  milestone 
(24:44-47).  The  budget :rq  cycle  also  affects  the  acquisition  process. 


The  budget  process  involves  both  DoD  and  Congress.  The  planning,  program¬ 
ming,  and  budgeting  system  ( P P B S )  is  a  key  DoD  step  in  weapon  system  acquisi 
tion.  "Approval  at  the  [program  Objective  Memorandum]  POM  constitutes  the 
beginning  of  the  acquisition  process"  (24:43t.  The  PPBS  is  a  process  that 
identifies  needs,  determines  resource  requirements,  and  allocates  resources 
(31:81.  Each  RPBS  cycle  “results  in  the  annual  DoD  budget  request  which  cons 
to  tne  President  for  inclusion  in  the  budoet  ...  to  Congress"  <31:8). 


The  federal  budget  undergoes  a  rigorous  Conqressi onal  review  during  the 
budget  enactment  process.  Three  Key  committees  in  Congress  review  defense 
programs  and  budgets.  This  review  often  changes  both  programs  and  budgets 
(26:178-196).  As  a  result,  this  process  is  also  a  factor  for  analysis. 


ANALYSIS  APPROACH 

To  determine  the  appropriate  contract  pricing  arrangement  for  software 
developments,  this  staff  analysis  project  determines  characteristics  ot  the 
procurement,  acquisition,  budget,  and  software  development  processes  that 
affect  the  selection  of  a  pricinq  arrangement.  The  pricing  arrangement  selec¬ 
tion  criteria  are  the  FAR  contract  applications  and  limitations.  This  analysis 
approach,  shown  in  Figure  2,  relies  heavily  on  direct  data  sources. 


ACQUISITION 

CHARACTERISTICS 


SOFTWARE  DEVELOPMENT 
CHARACTERISTICS 


\j ota  ' j o u r c e s 

Sources  tor  ttie  procurement  process;  analysis  are  the  t  ah ,  .•<  <  , 

sition  Regulation  (DAR)  ,  Armed  Services  Procurement  Manual  ,  course  t.i.e'  i  . 
tor  Government  Contract  Law,  and  professional  journals  tnat  have  studies  any 
analyses  of  the  federal  procurement  system  and  its  application. 

Sources  for  the  acquisition  process  analysis  are  DoD  directives,  military 
standards,  Air  Force  regulations,  guidebooks  on  acquisitions,  and  professional 
journals  that  report  results  from  acquisition  process  studies  and  analyses. 

Sources  for  budget  (PPBS  and  enactment)  characteristics  are  Air  Command 
and  Staff  College  phase  material  and  professional  acquisition  journals  the* 
eport  results  of  analyses  of  the  budgeting  process. 

Sources  for  analysis  of  the  software  development  process  are  Dob  uu  t?: 
fives,  military  standards,  Air  Force  regulations,  guidebooks  on  acquisitions, 
and  professional  journals  that  report  results  from  studies  and  analyses  of  the 
software  development  process. 

Limitations 

It  is  possible  to  classify  weapon  system  software  into  three  categories: 
operational,  support,  and  auxiliary  software.  Operational  software  are  comput 
er  programs  with  a  direct  link  to  the  weapon  system.  Support  software  are 
computer  programs  needed  to  maintain  weapon  systems  but  not  directly  linked  to 
the  system.  Auxiliary  software  are  computer  programs  used  to  develop,  test,  or 
maintain  operational  or  support  software.  This  study  only  considers  opera¬ 
tional  software  development  because  that  software  is  critical  in  satisfying 
operational  weapon  system  requirements. 

SUMMARY 

The  increasing  debate  within  Congress  on  budget  cuts  to  reduce  the  defi¬ 
cit  demand  that  the  Government  procure  its  needed  systems  properly  (23:62). 
Software  is  now  a  critical  weapon  system  cost  and  performance  element.  The 
Department  of  Defense  must  properly  procure  this  major  element  and  correct  the 
mismatch  between  software  acquisition  and  contract  type.  The  first  step  in 
determining  the  appropriate  contract  type  is  to  consider  the  Government  weapon 
system  procurement  process. 


Chapter  two 


'  hl  u  v  t  i-  n  fl  t  N  i  WE n PON  SVSTEM  PROCUREMENT  FAuCESG 

rrrmrn'  a  w  a  r  d  %  contracts  to  "acquire  necessary  supplies  and 
servi  ••*5  o»  :re  desired  quality,  in  a  timely  manner,  and  at  a  fair  and  reason¬ 
ed!:  c  r  i  r  .  he  procurement  process  is  the  same  regardless  of  the 

'supplies  ■»  :•  sr, ice:  .  However,  the  acquisition  process  described  in  the 
i'f’.ce  of  Ma.' aqeii.el.r  ar.s  Budget  i  0MB  *  Circular  A- 189  structures  weapon  system 
o  •  -el op  me/  is.  Ihe  Dudqet  process  affects  both  procurement  and  acquisition. 

n ;  =  chapter  de::rnces  these  processes  and  their  impacts  on  contract  selection 
h-  first  discussing  tne  federal  regulatory  system  for  procurement.  It  then 
Jv  ■  ices  a:  qu  i  s  1 1 1  or. ,  fiscal  (budget!,  and  research  and  development  ( R  i<  D ) 

. lea  ;n  the  government  weapon  system  procurement  process.  Finally,  it  summa- 
..  ons  :  de,"  at  l  ons  for  contract  pricing  arrangements. 


ID?  ?§9yi?l9Di!  Syftem 

c  emp .  i  sni  ng  the  immediate  objective  of  quality,  timeliness,  and  a  "fair 
a  a  s  o  n  a  1 1  e  price"  requires  satisfying  restrictions  from  agency  policies 
and  . aws  enacted  ov  Congress.  Because  of  these  restr l ct i ons ,  Government  repre- 
.  er.  t  .-.i  i  •,  es  are  not  tree  to  obtain  supplies  and  services  in  an  arbitrary  man¬ 
ner.  agencies  of  the  Government  have  only  a  limited,  specifically  delegated 
authority  to  contract  >14:1).  On  the  other  hand,  private  parties  or  companies 
ma/  generally  contract  as  they  please.  While  the  private  party  is  concerned 
with  rules  or  laws  that  would  prevent  a  specific  contract  action,  the  Govern- 
tiavi  representative  must  determine  a  legal  authority  which  permits  a  specific 
contract  action  i 1 4 : 1  - 2 1 . 

Ac  a  result,  Government  contract  law  is  highly  specialised  and  complex. 
'_£cal  authority  includes  statutes,  executive  orders,  judicial  decisions,  and 
regulations.  The  Federal  Acquisition  Regulation  iFAR)  is  especially  important. 
RAF  provisions  are  issued  under  statutory  authority,  have  the  force  and  effect 
ct  law,  and  provide  mandatory  contract  clauses  (18:1).  The  FAR  establishes  e. 
single  regulation  for  all  Executive  agencies  procuring  supplies  and  services 
v.itn  appropriated  funds  (funds  budgeted  by  Congress).  As  a  replacement  for  the 
Firmed  Services  Procurement  Regulation  (ASPRi,  Defense  Acquisition  Regulation 
(LAP  *  .  and  NASA  procurement  regulations,  the  FAR  is  intended  to: 

a.  produce  a  clear,  under st andab ! e  document  that  improves  uniformity 
in  the  acquisition  process; 

b.  reduce  the  growth  of  agency  acquisition  regulations; 

c.  implement  recent  recommendations  from  Federal  ana  Congressional 
commissions;  ana 
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d.  improve  agency,  industry,  and  public  participation  in  developing 
and  maintaining  regulatory  constraints  <1S:1). 

Government  Versus  Private  Contracting 

The  FAR  places  strict  limits  on  Government  contracts.  These  limits  are 
partially  due  to  inherent  differences  between  Government  and  private  contract¬ 
ing.  Differences  fo r  Government  contracting  include:  public  policy  objectives 
for  ensuring  legal  equality  of  all  private  parties  (treat  everyone  the  same), 
social  objectives  (minority-hiring  goals),  and  public  oversight  of  funds 
.extensive  cost  accounting).  Table  1  shows  a  more  detailed  comparison  of 
federal  versus  private  procurements. 


Area 

Federal 

Private 

1.  Status  of  parties 

government  writes 
rules  or  is  pre¬ 
eminent  party 

legal  status  of 
supplier  and  buyer 
equal 

advantage  company 
sire  or  financial 

status 

2.  Accountabi 1 l tv 

oversight  of  funds 

legal  procedures 

political  review 

public  access 

general  accounting 
standards  and 

ethics 

3.  Contracting  process 

detailed  procedures 

relatively  simple 

detailed  documen¬ 
tation  standards 

legal  r estr i ct l ons 

individual  company 
policies,  standards, 
and  documentation 

4 .  Objectives 

publ i c  use /benef 1 1 

production  needs 

agency  use  only 

commercial  needs 

multiple  objectives 

prof  it  and  loss 

see  t  a l  goal s 

c ompet i 1 1 ve  posture 

bid  '.(Bake  an  offer;  on  needed  services  or  supplies.  Ir.  esse 
cases,  the  contracting  office  releases  a  draft  SOW  for  cowmen:. 

c.  Selection  -  The  procuring  agency  evaluates  all  offers.  Ire  e. fi¬ 
liation  criteria  may  be  price,  technical  capabilities,  or  a  com¬ 
bination  cf  price  and  other  factors. 

d.  Auard  -  The  Government  accepts  an  offer  and  signs  a  contract. 

e.  Contract  adw in  1 str at  1 jh  -  The  contractor  performs  the  specific 
contract  tasks.  Both  the  contractor  and  tne  contracting  agency 
perform  contract  management. 

A  fey  part  cf  this  procurement  process  is  to  determine  contract  strategy. 
This  includes  determining  pricing  arrangement. 

Facing  Arrangements 

Part  cf  contract  strategy  is  selecting  a  pricing  arrangement  such  as  a 
fi red-price  or  a  cost -rei mbur semenfc  contract.  In  the  fixed-price  arrangement 
the  contractor  agrees  to  deliver  a  product  or  perform  a  service  while  the 
Government  agrees  to  pay  a  price  equal  to  the  firm  price  specified  in  the  con¬ 
tract.  The  contractor  s  actual  costs  have  no  effect  on  the  agreement  tr  Deliv¬ 
er  nor  on  the  Government  s  agreement  to  pay.  The  contractor's  ability  to  avoid 
a  loss  or  make  a  profit  is  directly  related  to  controlling  costs.  Ir  actual 
costs  are  less  than  the  negotiated  price,  the  difference  is  profit.  It  actual 
costs  are  more,  che  difference  is  loss.  The  con tractcr  assumes  tne  performance 
risls  in  a  f  i  ••  ed- price  contract  ( 15:  2C1-2C24  J . 

In  ccst -r  e  ivbur  sewer,  t  efforts, the  Government  ag-ees  to  reimburse  the 
contractor  for  all  reasonable  and  allowable  costs  that  are  allocable  to  con¬ 
tract  performance  ( 1 5 : 2C 1 -2C24 <  .  The  contractor  agrees  only  to  use  a  best 
effort  tc  complete  the  contract  within  cost  estimates.  The  contractor  is  not 
obligated  to  continue  performance  -when  the  estimate  is  exceeded  nor  is  the 
Government  obligated  to  reimburse  costs  in  excess  of  the  original  estimate 
> 15: 2C 1 -2C24 > .  In  this  contract  type,  the  Government  assumes  performance  risk 
since  t‘e  Government  must  pay  whatever  costs  are  required  to  complete  the 
effort  or  he  satisfied  with  whatever  effort  was  made. 

The  FAF  discusses  selecting  appropriate  pricing  arrangements.  Pricing 
arrangements  stimulate  the  performance  of  the  contractor  doing  the  wen  by 
defining  several  wavs  for  the  contractor  to  receive  payment  and  profit.  The 
choi ce  of  a  fixed -price  cr  cost-re; at  or  semen t  contract  often  rests  go  perfor¬ 
mance  risk.  The  FAR  and  the  Armed  Se- vices  Procurement  Manual  address  contract 
type.  risk,  enc-  profit  relationships: 

1.  Both  tie  Government  and  the  contractor  should  be  corcerner  * ;  '  h 
harnessing  the  profit  motive  in  stimulating  performance. 

2.  Su.c  oss  in  effectively  harnessing  this  motive  requires  nepotic t 
i  r,  g  sound  jerf  oruance  goals  and  standards. 

T.  Cent -act  type  should  tie  p-ofits  tc  contractor  effic.erc.  in 
controlling  costs  ar.d  meeting  pe'former.ce,  reliability,  _ua.it., 
and  delivery  requirements. 

A.  Thera  ar e  situations  where  the  profit  motive  may  he  seccnaar.. 

5.  The  firm  *;xed-prica  contract  is  the  nos:  g-eferred  method 


ClCl!‘zEi^l5lCLLh§__iLp?i._Q9GtC§tti  The  f 1 r  a- f  1  ed -pr 1 ce  contract  provides 
for  a  payment  which  is  not  subject  to  any  adjustment  for  actual  costs.  The 
difference  between  negotiated  and  actual  costs  is  profit  or  ioss.  This  type  of 
contract  places  maximum  risk  upon  the  contractor.  The  FTP  contract  is  suitable 
when  reasonably  definite  design  cr  performance  specifications  are  a.  a  liable 
and  the  Government  can  establish  price  (15:2C3:  17:16. jj. 

LLZ|b;Pr  i_cey[ncent  ive;;Fee_  (FPIF  l_Contract  t  The  PPIF  contract  is  a  tmed- 
price  type  contract  with  a  provision  for  adjusting  protit.  How  well  the  con 
tractor  meets  performance  or  delivery  requirements  increases  or  decreases 
profit.  FPIF  contracts  are  appropriate  where  incentives  can  improve  perfor¬ 
mance  levels  or  delivery.  F 1  :<  ed-pr  i  ce  - 1  ncen  1 1  ve-f  ee  contracts  should  not  ce 
used  unless  the  contractor  has  an  adequate  accounting  system.  Ar.  FPIF  should 
not  be  used  unless  it  is  likely  to  be  less  costly  than  other  methods  c; 
contracting  for  the  same  item  < 1 5: 2C4-2C9;  17:1 6.403). 

Cost  ;F'l.u|;  I  Qcent  ryt^Fee _ |CP  IF  i__Con  tract .  The  cost-plus-incentive- fee 

contract  is  a  c cs t - rei *bur semen t  contract  with  adjustments  in  fee  '.profit*. 
The  relationship  of  actual  costs  to  target  cost  increases  or  decreases  profit. 
The  CF'IF  contract  is  suitable  primarily  for  development  and  test.  It  should  be 
used  when  it  is  likely  that  a  profit  adjustment  is  a  positive  incentive  for 
effective  management.  The  CF'IF  contract  is  appropriate  when  development  is 
highly  feasible,  there  are  well-defined  performance  objectives,  and  tne  con¬ 
tract  is  admi  r.i  strat  i  vel  y  practical  to  manage  f  15:  2C15-2C1  Si  17:16.404-11. 

Q9§t  i£l  us-Fi.xed;Fee _ <CF;FF  i__Con  tract  t  The  CPFF  contract  is  a  cost-rpim- 

bursement  contract  wnere  fee  (profit1  does  not  vary  with  actual  costs  or 
performance.  Because  fee  does  not  vary,  tnere  may  be  only  a  minimum  incentive 
for  effective  management  of  costs.  The  CPFF  contract  is  suitable  fer  research 
projects  or  when  the  needed  level -of -ef fort  is  unknown.  This  type  of  contrac; 
normally  should  not  be  used  for  development  of  major  weapons  where  there  is  a 
high  probability  that  development,  performance  objectives,  and  schedule  are 
achievable  < 15: 2C21-2C24;  17:16.3). 

'iQisZtiiit.A.war  d;F§§_  iQFAF  j__Con  tr  ac  t The  CPAF  contract  is  a  cost -reim¬ 
bursement  contract  with  special  fee  (profit'  provisions.  It  provides  a  profit 
incentive  in  cases  where  it  is  difficult  to  quantitatively  measure  perfor¬ 
mance.  Award  criteria  vary,  but  may  include  quality,  management,  and  schedule 
factors.  The  CPAF  contract  is  suitable  for  1 e vel -of - ef f cr t  contracts  where  the 
performance  of  services  is  clear  but  determining  level  of  achievement  is 
subjective.  It  is  also  suitable  for  efforts  where  it  is  difficult  to  establish 
definite  milestones.  There  are  limitations  to  its  use:  it  should  not  be  used 
tc  avoid  a  CPFF  contract,  or  when  p-ocurement  is  for  Engineering  Development 
or  Cperat  i  onal  System  Development  activities  1 15: 2C 13 - 2C2 1 ;  17:16.404.:-). 
These  activities  are  parr  of  the  FAf:  s  F:t<D  cycle  for  a  system  life  cycle. 


System  L  l  <  e  Cycle  M  g d e 1 | 

The  tot.-!  system  .lie  cycle.  Figure  5 ,  includes  system  ac  q.:i  si  c  i  on  . 
'  e-rearch  and  de  -  el  cement  (P-'D)  ,  and  fiscal  year  budget  c.cies.  A  weapon  s,  s*em 
lire  .  y c  1  e .  as  def  i ned  in  a F R  6<?2I-  2 ,  “°rour am  Management ,  and  a  F  P  a i 0  , 


cept,  guidance,  and  policies  for  major  weapon  systems  acquisition;  the  second 
provides  specific  tasks  and  responsibilities  (24:41-42).  While  there  is  now 
some  flexibility  in  scheduling  milestones,  each  milestone  has  a  specific 
purpose: 

a.  At  Milestone  (?,  the  Secretary  of  Defense  approves  the  start  of  a 
new  program  following  analyses  that  identify  a  mission  need. 

b.  At  Milestone  1 ,  the  Secretary  of  Defense,  after  a  DSARC  review 
and  recommendation,  selects  a  specific  concept  from  a  number  of 
alternatives  based  on  such  factors  as  costs,  schedules,  mission 
objectives,  supportability,  industrial  base,  and  affordability. 
This  milestone  occurs  at  the  end  of  the  concept  exploration 
phase.  Concept  exploration  emphasizes  identifying  alternatives 
and  maintaining  competition. 

c.  At  Milestone  11 ,  again  following  a  DSARC  review  and  recommenda¬ 
tion,  the  Secretary  of  Defense  gives  approval  to  begin  or  proceed 
with  full-scale  development  based  on  performance  definition, 
costs,  schedules,  risks,  and  supportability.  This  milestone  nor¬ 
mally  occurs  at  the  end  of  the  demonstration  and  validation  phase 
where  there  is  extensive  prototype  testing.  It  may  occur  later  in 
the  system  development  phase  to  refine  cost,  schedule,  and  per¬ 
formance  requirements  or  estimates. 

d.  At  Milestone  111 ,  either  the  Service  Secretary  or  the  Secretary 
of  Defense  decides  to  produce  and  deploy  the  system  (24:43-47). 

Although  the  DSARC  review  process  instills  discipline  into  acquisition, 
it  also  has  faults  <22:4,53;  3:13).  A  recent  study  of  16  programs  developed 

under  the  DSARC  process  concludes  that  although  effective,  the  review  process 
is  inefficient  (22:iv).  Among  the  inefficiencies  are: 

a.  decisions  are  not  considered  to  be  binding  budget  decisions-- 
since  the  budget  process  operates  independently  of  the  DSARC 
review  process,  changes  to  programs  often  do  not  find  their  wav 
into  the  budget,  are  appealed  during  the  budget  process,  or  are 
reversed  during  the  budget  cycle; 

b.  there  is  a  perception  of  mi cromanagement--rather  than  considering 
broad  system  issues,  DSARC  reviews  overemphasize  technical  issues 
and  engineering  solutions  at  subsystem  or  component  levels; 

c.  strategies  and  program  direction  change  whenever  the  staff 
changes  (every  2-3  years) --al ternati ves  are  r econsi dered ,  studies 
reaccompl l shed ,  and  previous  phases  repeated  as  the  new  staff 
reviews  earlier  efforts;  and 

d.  Congressional  author i z at l on  or  appropriation  bills  often  include 
program  tasks,  limitations,  and  guidance  (22:51-55). 

Fiscal  Cycle 

The  Planning,  Programming,  and  Budgeting  System  (PPBS)  ends  in  the  DoL> 
budget  input  for  the  Congressional  budget  process.  Although  the  PPBS  complete? 
a  cycle  each  year,  "several  cycles  are  in  progress  simultaneously"  <31:8». 
Because  of  that,  the  PPBS  cycle  is  not  time-phased  exactly  as  shown  in  Fiqure 
5,  but  is  a  series  of  overlapping  cycles.  These  two  interrelated  PPBS  and 
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pr  ,.r  instability.  F'rfcb  contribute;  to  cost  increase-,  >  a  wesr  • 

reason  is  a  teroenc,  to  ensure  program  Funding  tor  tne  upcoit.  :  • 

••  a'  tr.e  expense  o»  long -tern  weapon  s>  stem  i  mpl  i  cat  i  ons  I  «.* .  1  <  . 

r  -met :  nes  purposely  under  stated  ei  ther  our ause  .:u  .a;  i  ~; 

d-'oc.  to  r :  t  aval  »  oit  Funding  rattier  than  tne  tunc:  r-g  requite.  t;.  •:  • 

or  becau'o  cm,  tractors  purpose  1  v  lowered  tneir  erst  fit  i  sates  * 

'rot'  '  .1'  7  :  9  6  >  .  As  a  result,  prcnr  am  costs  tor  later  t  •  sr  a :  •  ?.  s  .  -  .  ju 

uepes  c  f  ecovering.  'his  produces  i  r,  stability  in  program  e  q  ■  i  r  e  t  s , , : 

i ;  t:  i  e  i .  :  t:  i  s  -  eentor-.es  Congress  '  view  that  "ear;-  cost ,  srheciuc  .  arc. 

term  a  o  c  o  estimates  are  consistently  overly  optimistic  and  nig  hi  ,•  u  n  : 


inability  to  enact  budget  1 eoi  =  1  at l o n  o  -  r r 
program  stability.  Congress  uses  a  cor.tinu, 
programs  when  it  tails  to  enact  budget  legi; 
allows  tne  expenditure  of  Funds  at  the  c u r ' 
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del  3 .  •:  c  r  omen  t  actions  and  puts  programs  on  hole.  Among  ins  ;  .*• 
difficult/  in  icng-range  planning;  reduced  management  1 1  e  y  l  c i  1  1 1  v ; 
nce.-t  a  ,  nty ;  and  unstable  program  schedules  (28:1  96).  To  seme  d? 
■  ;  m  c  sets  o :  c  u •?  v  e  r  v  year  . 


u  r,  a  - 


io,  .ear.  19  3  3  - 1  9  3  4  began  with  a  continuing  resolution  ranging  *  -  o  -  ,J 
*•  1.  vise's  with  an  average  of  10  1  ;2  weeks  before  Congress  enacted  a 
o u o  j u  r  v  4  ,  -  - ;  .  T n i  s  p r o o  1  e m  is  a  r e c u r r  i  n g  one.  “Since  1  97  2,  thirty- 
r  t  .  ,n  •  j  i  n  g  resolutions  have  been  enacted  into  law  .  .  .  Since  1 976  .  .  . 
:  e  wo  -  u  all  appropr  i  ati  or.s  bills  enacted  by  the  beginning  of  the  fiscal 
.n  that  vear  a  continuing  resolution  was  needed  to  fund  some 
s  “  *  S :  1  v  6  f 

■  -  c  jt  el.'27'zD!  Cycle 

•  e .  r  u  3  development  cvcle  in  tne  system  model  ,  f.gure  5.  con 

■  .  important  activities  for  pricing  arrangement  considerations.  The 
•-  c  '"ese  activities  as  an  aid  in  determining  pricing  arc  ange-nent . 

■  i  .  s  s  arc: 


•  •  i  includes  all  scientific  study  and  experimentation 

t  s  directed  toward  increasing  knowledge  and  under  stand  ng 

•  rs-so  fields  of  the  physical,  engineering,  environmental  and 
,  f  e  .is'-.ea  related  to  long-term  national  security  needs.  It 

■-■  '■s  fundament  a  i  knowledge  required  for  the  solution  of  »i  '•  i  • 

.  ■  ’  >  o  1  e  >ti  s  . 

.  ;  i .  ■ "  <9  r .  ■ .  y  pc-  v  e  i  .-■>  a#  a  r*  t  -  includes  all  efforts  directed  t  cw<  r  .1 
'  i.  ;  ol.it  ion  of  specific  military  problems,  short  of  major  dc-.ci- 
;  it.  ft  projects.  It  involves  only  minor  a  eve  lop  men  t  effort.  Inc 
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characteristic 
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is  evaluating  proDO-et 
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military  problems 

for  f  e  a  s i b l i  .  t  v 
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d  e  .  e 1  c  p  i  n  q  protctvpe  Hardware  -for  teat.  The  prime  res  a  it  c  * 
tvpe  o f  effort  15  proof  of  a  design  concent  rattier  tr.-n 
Hardware  d e v e i  c p ,m e n t . 

d .  Engineering  Developae’t  -  includes  any  projects  m  hu ' -scale 
engineering  development.  There  is  no  approval  for  system  p-orv: 
lion  yet. 

e.  Operational  Sy stea  Development  -  includes  those  projects  stil: 

in  full-scale  engineering  development  Put  with  approval  for  pro¬ 
duction  '.16:4-101;  17:16.184). 

There  are  doth  general  and  specific  pricing  arrangement  guidelines  tor 
those  R&D  activities.  General  guidelines  include: 

a.  A  contract  other  than  FfP  should  Pe  used  when:  contracting  rC- 
research  and  develop a ent;  when  price  competition  i s  not  present: 
when  cost  or  pricing  data  available  does  not  permit  sufficiently' 
realistic  estimates  of  probable  cost  of  performance:  or  uncer- 
tainties  cannot  be  evaluated. 

b.  It  is  possible  for  different  parts  of  a  project  to  tit  several 
different  categories.  The  contract  must  be  selected  to  tit  the 
work  required  not  the  program  c  1  a ssi  f  i  ca 1 1  on  117:  Part  16). 

There  are  also  specific  guidelines,  Table  2,  that  describe  characteris¬ 
tics  of  the  R3.D  phases  and  the  appropriate  contract  types  for  each  phase.  As 
shown,  there  is  more  than  one  appropriate  contract  fo’’  any  general  R&D  activi¬ 
ty.  Specific  projects  may  have  other  considerations  for  a  final  contract 
selection.  Table  2  groups  together  R&D  categories  with  similar  char  act er i s~ 
tics. 


The  Research  and  Exploratory  Development  categories  have  similar  charac¬ 
teristics.  An  important  one  is  a  lack  of  definitive  requirements.  As  a  result, 
several  cost -r ei mb ur sement  contracts  are  appropriate.  The  selection  depends  on 
other  factors  including  risk.  Similarly,  the  Engineering  Development  category 
shares  such  coamon  characteristics  as  engineering  design  and  prototypes  with 
tne  Operational  System  Development  category.  In  this  case,  the  degree  of 
project  definition  frequiremen ts>  and  risk  are  among  factors  to  consider. 

There  are  few  restrictions  in  the  Advanced  Development  category .  Because 
this  phase  often  has  many  major  changes  as  a  result  of  systems  analysis  and 
cost  studies,  the  contract  is  usually  a  CPFF.  In  cases  where  it  is  possible  to 
define  measurable  cost,  schedule,  or  performance  criteria,  incentives  are 
Possible. 


w*  U  t7!  3  r  '£ 


The  weapon  s.stem  procurement  process  includes  procurement,  acquisition 
and  budget  processes.  The  procurement  process  defines  hew  to  contract  a no  when 
to  U:,e  certain  pricing  ar  r  angemen  t  s .  In  general,  when  r  i  si  15  mini  me!,  ,  tit 
1  on  tract  1  vppr  L.pr  :  ate.  As  uncertainties  increase,  huwe.er,  cost  *  i  1  mbut  nr 
me'  t  contracts  are  appropriate.  ns  an  aid  in  that  selection,  the  FAn  del. nee 
fib  categories  that  are  similar  to  acouisition  process  activities.  The  scaur 


sitior.  process  formalizes  weapon  system  development.  Congress  not  only  affects 
these  processes  curing  the  budget  process  as  it  reviews  programs,  but  also  o v 
its  inability  to  pass  a  budget  at  the  start  of  a  fiscal  year.  The  following 
characteristics  result  from  the  interrelationship  of  ail  these  activities: 

a.  while  the  DSARC  review  process  is  effective  in  formally  reviewing 
programs,  it  is  inef  f  icient — continued  review,  micromanagement, 
and  resulting  program  instability;  and 

b.  budget  and  fiscal  cycles  add  to  program  1 nstabi 1 i tv--unreal 1 st : c 
program  costs,  lack  of  a  budget  at  the  start  of  the  fiscal  year, 
and  Congressional  program  direction  in  budget  bills. 

These  general  factors  for  weapon  system  development  are  considerations 
when  selecting  pricing  arrangements.  The  next  step  is  to  specifically  consider 
software  development  for  other  factors  affecting  pricing  arrangement. 


C  n  a  p  t  e  r  Inree 


SOFTWARE  DEVELOPMENT 

ur  l-c  :  cue  mi  smatcn  between  software  acquisition  and  coni. r  acts  r  e- 
r  m  j  cat  a-  i  <?3  i  oo  k  at  software  development.  This  chapte:  high!  iqntd  i  s  - 
;  .oe  tv  and  obi  ems  with  sot  t  ware  and  describes  tne  current  501  >.  war  a 
riutaan:  model.  it  tnen  describes  changes  in  that  model  as  a  reaction  to 

t .  '  problems.  Finally,  it  su  mm  antes  software  development  character: s:  ,  cs 
►  ■'  n  0  r  1  •:  1  r,  q  arr  a n q  e m e n  t . 

SOFTWARE  COSIS  AND  PROBLEMS 

1  :*t»-ars  development  is  a  major  weapon  system  cost.  There  are  estimates 
•  bh-P'ilv  of  the  acquisition  costs  of  major  Air  Force  weapon  systems  are  tor 
tware  development  (30:19).  Additionally.  the  DcD  software  investment  wili 
w  f ,  t j 4  billion  in  1984  (9:10;  13:46).  While  these  costs  often  resuit  iron 
am;  1 ng  software  applications,  high  software  costs  are  also  due  to  dove  1  op - 
factorm  Ins  following  are  major  examples: 

a  tne  labor-intensive  aspect  of  software  development  often  requir¬ 
ing  highly  skilled  and  creative  programmers; 
b.  extensive  software  testing  during  development; 

:.  changes  ir  a  program's  design  and  code  as  errors  are  found  and 
then  corrected;  and 
d.  vague  or  changing  requirements. 

A  r. :  t  n  a  r  >-  eusor  is  the  cost  to  maintain  software.  "The  cost  0  t  m  a  1  n  t  aim  n  n 
U'ji'S  is  estimated  to  account  for  about  75  percent  ot  software  costs’’ 
30: .  The  above  reasons  for  high  software  development  cost  also  apply  t  c  the 
n  :  s  t  a:  maintaining  software.  While  hardwar e  is  maintained  b  v  replacing 
n  cr  fai:ed  parts  with  new  ones,  it  1 s  not  possible  to  maintain  software  by 
e ’  r  q  1  -  with  an  identical  copy  of  the  original  program.  Software  main- 
cenc :  means  redesign  requiring  the  same  tools,  techniques.  and  skills  as 
el  go  meat  (11:343;.  That  redesign  is  often  to  correct  software  so  "much  0  + 
s  f.-oense  tfor  software  maintenance!  is  attributable  to  time  spent  M  mm, 
software  that  was  not  correctly  developed  in  the  first  place"  i6:23  . 

m  need  to  fix  software  is  one  problem  with  software  bevel  op  mm  c . 
'vs  are  overruns,  late  deliveries,  and  system  failure.  These  often  occ.  .  m 
same  time.  Cost  overruns  of  "f our  times  the  original  estimates-  .  .  .  with 
f  tne  planned  capability  are  not  uncommon"  (30:5).  Overruns  often  occur 
am.  of  an  inability  to  accurately  estimate  costs. 


Models  for  est 1  mat  1 rg  software  costs  are  “poor  ana  there  is  little  corre¬ 
lation  frao  one  model  to  another"  ; 13:67) _  Particularly  critical  for  weapon 
system  software  acquisition  is  that  models  “dG  not  produce  good  estimates  3  to 
5  years  in  advance,  at  the  time  the  initial  budgeting  estimates  are  made  m 
the  Program  Objective  Memorandum"  {30:5).  With  the  difficulty  in  estimating 
costs,  the  resulting  cost,  schedule,  and  performance  problems  are  not  surpris¬ 
ing.  Another  reason  given  for  those  problems  is  failure,  to  follow  an  ade¬ 
quately  structured  and  properly  managed  development  process  (21:1;  13:63), 

SQFJWABI  DEVELOPMENT;  PROCESS 

To  follow  a  structured  and  properly  managed  software  development  process 
requires  recognizing  both  the  role  and  nature  of  software.  The  software  '■ole 
changes  during  weapon  system  development.  In  early  phases  of  weapon  system 
development,  software  supports  hardware  engineering  models  and  prototype 
tests.  As  the  system  development  progresses,  software  supports  test  tool  and 
simulation  development  while  continuing  to  support  hardware  development.  Fi¬ 
nally,  software  is  a  distinct  product  in  the.  weapon  system.  With  ali  these 
roles,  a  properly  structured  and  managed  development  must  plan  to  both  develop 
software  and  support  other  activities.  Software  can  readily  support  otner 
activities  because  of  its  nature. 

t 

Software  programs  are  easy  to  modify  while  software  development  is  itera¬ 
tive.  Software  modi f i cat i ons  can  quickly  change  system  functions  for  hardware 
tests,  new  requirements,  or  design  corrections  (13:69).  (Appendix  A  gives 
examples  Gf  modifying  software  to  improve  system  functions.)  This  creates  the 
incorrect  impression  that  since  it  is  easy  to  modify  software,  modifying 
soft  war  e  i s  easy . 

Modifying  software  is  not  easy  because  it-  means  redesigning  the  program. 
This  requires  analysis,  coding,  and  testing--the  same  tasks  needed  to  develop 
software.  In  fact,  “current  practices  for  modifying  delivered  software  systems 
frequently  result  m  excess  costs,  failure  to  realize  performance  potential, 
land]  systems  out  of  action  for  unreasonable  lengths  of  time"  (13:69).  This 
means  yet  another  modification.  Developing  software  that  works  properly,  then, 
is  ar.  i  ter  at  i  ve-  process . 

t 

Software  development  is  iterative  because  of  changes  "to  make  the  system 
meet  the  original  r e qu i r emen t s "  (13:69).  Changes  often  correct  errors  which 
fall  into  one  of  three  categories:  requirements,  design,  or  code  (these  are 
also  three  software  development  ohases)  (5:94).  Regardless  of  the  system, 
software,  or  testing  program,  errors  are  detected  during  each  phase  of  soft¬ 
ware  development  “  .  .  .  from  every  major  category.  And  more  importantly, 
each  phase  caugnt  errors  which  should  have  been  detected  earlier"  (2:99).  This 
means  that  during  the  design  phase  there  are  errors  in  both  design  and  re- 
c -ii  ■- emen  t  s ;  and  during  the  test  phase,  there  are  errors  in  requirements, 
design,  and  code.  But  software  development  process  models  have  not  shown 
roftware  modifications  or  software  s  iterative  nature. 
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Figure  t- .  Software-  Development  Model 


t  s  c  h  n  1  -  a ,  r  t  ,  1  e  w  and  audit  t<  a  s  1  specific  purpose.  ■'  e  c  r,  a  1  c  a 
ew.->  emphasize  er^;  nee-- :  ng  and  design  while  audit?  tJ.imsi 
■  i  ■-  a  1 1  0 r.  and  rent:  g yr  at  '  or.  verification; 


1.  S/steffl  Design  Reviews  ;5Cf;  l  an  tc  evaluate  foe  entire 
concept  ‘hardware  and  software)  and  the  flist'iDal: on  of 


V 


requirements  to  each  item; 

Preliminary  Design  Reviews  (PDR)  are  to  evaluate  pasic  software 
design  for  completeness,  adequacy,  and  compatibility  with  soft¬ 
ware  and  system  requirements: 

Critical  Design  Reviews  (CDR.»  are  to  evaluate  detailed  design 
prior  to  software  coding; 

Functional  Configuration  Audits  ( FC  A )  are  to  verify  software  per¬ 
formance  against  requirements;  and 

Physical  Con f 1 qur a 1 1  on  Audits  tPCA)  are  to  examine  the  coded 
proaram  against  its  documentation  prior  to  Government  acceptance 
•  2  <? :  C  h  4  '  . 


THE  CHANGING  bOFfWARE  MODEL 

In  reality,  software  phases  are  not  distinct  or  sequential  steps.  Re¬ 
quirements  analysis  does  not  stop  at  a  distinct  point,  nor  does  preliminary 
design  wait  until  all  requirements  are  defined.  Instead,  all  phases  blend 


together  tnroughout 
repeats  as  software 
occur  during  one 


software  development  as  in  Figure  ?. 
latures.  "Several  software  development 
system  development  life  cycle"  <25:5) 


all  phases  blend 
Each  phase  also 
life  cycles  .  .  . 
These  software 


:  f  e  cycles  are  software  modifications  in  response  to  new  requirements,  more 
“•icient  desior.  or  test  results. 


Development  H B y  1. i d s 


In  the  “build"  approach,  software  development  occurs  in  stages.  Early 
builds  of  the  software  have  basic  program  structure  and  a  subset  of  require¬ 
ments.  Incremental  development,  Figure  9,  allows  progressively  refined  builds 
that  add  to  or  expand  initial  capabilities.  Changes  can  be  incorporated  in  the 
next  version  or  delivery.  Figure  9  shows  an  offset  in  activities  to  indicate 
that  build  modules  are  time-phased  and  activities  overlap.  Factors  that  in¬ 
fluence  the  choice  of  requirements  for  the  first  build  are  hardware  develop¬ 
ment.  test-bed  requirements,  and  interface  definition.  In  specifically  defin¬ 
ing  each  version,  builds  help  to  manage  unstructured  and  uncontrolled  changes. 


BUILD  DEVELOPMENT  ACT  I  VI IV  MODULE 
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Figure  9.  Software  Development  "Build"  Approach 


There  are  several  wavs  to  define  the  capabilities  of  each  build. 
jii  l  del  i  nes  for  defining  distinct  builds  include: 

a.  ensure  the  build  is  functionally  logical  with  operations: 

b.  navi  mi  re  the  uniqueness  of  added  capabilities  in  each  build;  and 

c.  minimize  the  amount  of  modification  required  of  previous  builds 
for  the  new  increment  (7:271-277). 
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iterative  development  process.  Tnese  models  are  often  software  "builds" 
hat  control  changes  in  requirements.  design,  and  code.  Key  characteristics, 
hen,  wnen  selecting  a  pricing  arrangement  for  software  development  are: 

a.  changing  requirements; 

b.  poor  cost  estimation;  and 

c.  an  iterative  development  process. 

These  factors  indicate  that  software  development  is  a  high  risk  effort 
egardless  of  the  system  acquisition  phase.  The  final  step  to  correct  the  mis- 
atch  between  software  acquisition  and  contracts  is  to  relate  these  software 
■h ar ac t er  1  st  1  cs  and  the  Government  procurement  process  factors  from  Chapter 
wo  to  the  TAR  pricing  arrangement  guidelines. 


opr.ent  models,  these  designs  are  prototypes. 

Prototypes  are  complete  designs  to  test  prograra  requirements  ana  opera¬ 
tional  capabilities.  A  next  build  or  prototype  version  improves  design  and 
code  tor  patter  efficiency  or  use.  These  interim  versions  are  not  the  final 
product  but  a  means  to  arrive  at  the  final  design  and  program.  This  is  consis¬ 
tent  with  activities  in  the  FAR's  Engineering  Development  phase. 

FAR  CRITERIA  ANALYSIS 

Factors  in  selecting  a  contract  type  for  Engineering  Development  efforts. 
Table  2,  include  degree  of  project  definition,  accuracy  of  cost  estimates,  anc 
degree  of  Government  control  and  direction.  These  factors  determine  the  appro¬ 
priate  contract  type  (pricing  arrangement). 

F‘  r  o  j  e  c  t  Definition 

Weapon  system  program  stability  and  software  development  characteristics 
are  key  ingredients  for  project  definition.  The  conclusions  in  Chapter  Two 
indicate  that  weapon  systems  suffer  from  program  instability  (a  specific 
example  of  program  instability  is  in  Appendix  B) .  Even  if  that  was  not  the 
case,  software  development  problems  include  "original  requirements  that  are 
incomplete"  (5:73).  The  iterative  nature  of  software  development  includes 
changes  in  requirements.  This  is  additional  evidence  that  software  project 
definition  is  poor.  (Appendix  C  shows  an  example  of  reported  errors  in  re¬ 
quirements  throughout  development).  Software's  poor  project  definition  affects 
cost  estimate  accuracy  (32:2). 

Ac  cur ac y  of  Cost  Estimates 

There  are  a  number  of  reasons  why  it  is  difficult  to  estimate  software 
costs.  With  program  instability  and  ill-defined  or  vague  requirements,  "the 
resulting  cost  estimate  .  .  .  will  be  imprecise  and  undependable"  (32:2).  Ever, 
with  firm  r eaui r emen t s ,  "current  software  cost  estimation  (SCE)  models  do  not 
□reduce  good  "esults"  (30:5).  SCE  models  require  estimates  of  the  software 
program  sire  (30:5'.  But  size  estimates  are  inaccurate  (30:5).  Ever,  SCE  models 
with  factors  for  program  size,  complexity,  hardware,  personnel,  and  schedule 
give  different  estimates  for  the  same  project  (36:--).  The  size  of  the  program 
changes  during  development  as  modifications  occur. 

Modifications  during  development  to  fix  "software  that  was  not  correctly 
developed  in  the  first  place"  also  affect  cost  estimates  (6:28).  These  modifi¬ 
cations  occur  f r c m  review,  analysis,  and  test.  The  ability  to  predict  the 
rjmber  of  errors  or  changes  during  development  is  limited.  "All  error  preoi c  - 
‘.■or,  models  suffer  from  the  inability  to  p-eoict  to  the  accuracy  [desired]" 
' 4 : i 0 4 ' .  Because  of  that,  software  development  has  cost  risks. 

F  :  i  -  !_ 

The  FAR  discusses  ris)  in  terms  of  cost  and  performance.  Cost  r  i  s  f  ■-  a  •-  <  ■ 
primarily  adeouacv  of  Government  and  contractor  cost  estimates-  realist:,,-. 
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Cqst^Plus-Fijied-Fee  1CPFF  ^  Contract 

CPFF  contracts  are  suitable  tor  research  or  when  i  e  v  e  1  - o  t - e  t  ♦  o  r t  :c 
unknown.  As  discussed  above  and  earlier  in  Chapter  Three,  sottware  cost  esr 
mation  models  are  inaccurate,  Changing  requirements  and  modifications  t  tree  sn¬ 
out  development  make  sottware  level -of -effort  unknown.  this  contract  t , o e  n a  . 
be  appropriate  ‘or  sottware  developments. 

Cost-F'lus-Award^Fee  _i CF' AF  >  Contract 

CFAF  contracts  are  suitable  wnere  determining  the  level  ct  achievement  is 
subjective  or  where  it  is  difficult  to  establish  definite  milestones.  When 
different  software  designs  satisfy  requirements,  their  evaluation  is  subjec¬ 
tive.  Meeting  the  requirements  is  difficult.  Especially  difficult  is  estab¬ 
lishing  and  meeting  definite  milestones.  CPAF  contracts,  then,  may  alsc  p  e 
appropriate  for  a  weapon  system  software  development. 

SUMMARY 

Weapon  system  software  development  has  a  lack  of  firm  requirements, 
inadequate  cost  estimates,  and  extensive  Government  control  and  direction. 
These  are  also  pricing  arrangement  characteri sties  +  or  a  cost -rei mbur semen t 
contract.  The  characteristics  indicate  that  software  development  is  high  risl 
during  any  system  acquisition  phase.  High  risk  developments  normally  require  a 
cost -rei mbursement  contract  as  shown  earlier  in  Figure  4.  Reviewing  the  three 
major  cost  contracts  to  answer  the  question  what  contract  pricino  arrangement . 
as  described  in  the  Federal  Acquisition  Regulation  iFARi  is  appropriate  for 
the  development  of  operational  software  during  weapon  system  acquisition  gives 
this  answer:  a  v  ost-r  e  i®  bar  spite  nt  ■:  nr  *  r  ac  t  --  e  1 1  he  r  cost-plus-  fixed -T?e  it'Pff' 
or  co s t - p l u s  ■  auar d-1 e e  c  CPAF) .  The  important  part  of  this  conclusion  is  that 
sottware  development  requires  a  cost-reimbursement  contract.  A  selection  be¬ 
tween  a  CPFF  or  CPAF  requires  additional  specific  acquisition  considerations. 
The  individual  software  program,  type  of  functions,  previous  experience, 
computer  system,  and  other  areas  would  help  choose  between  a  CPFF  or  CPFF 
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PHD  R-M  0075(12),  undated,  implementeo  decisions  to  Case 
Peacekeeper  missiles  in  existing  Minuteman  silos  and  Sir 
additional  basing  studies  to  include  the  small  missle. 

PHD  R-M  0075(13),  dated  Sep  1983,  initiated  Peacekeeper  mi 
production  and  directed  engineering  design  and  demonstrable 
small,  single  warhead  missiles,  hard  missile  silos,  and 
basing. 

PMD  B075(14),  dated  Sep  1983,  directed  cesign,  development 
test  of  a  common  ALCC  capability  for  Peacekeeper  and  Minutem 

PMD  0075(15),  dated  Oct  1984,  updated  program  funding. 

PMD  3075(16),  undated,  provided  further  guidance  on  the 
AL Cl  capability  and  updated  program  funding. 
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both  a  developing  contractor  and  a  second,  1  noepfcr.a  =  ht  tor.  tt  »*<  r. .  ■  r.  -j 
Mi  nuteman  so+tware  programs.  This  approach  is  very  s-jccestt  ■  t  i q 

systems  that  work  proper  i  v.  Throughout  tne  d-  *-e!  op»vnt  mat  e  two  :  onu  .  . ;  *  r  ; 
tind  errors  in  requirements,  a  •: r  qn ,  ana  code.  These  e  r  r  % r  s  or  anomalies 
resolved  with  no  change  .  jet  erred  changes,  or  a  cnarsoe  in  '.no  software. 

>  :  owing  summary  is  From  anomalies  report  eg  b  v  an  1 n depen gen t  contractor  s 

a .  j  /  4  anomalies  on  two  projects,  each  with  three  sot  t war  e  programs . 
Here  reported; 

b.  171  of  the  anomalies  were  reported  against  requirements; 
against  design/code; 

c.  Requirements  anomalies  were  reported  both  before  ana  af^er 
coding;  and 

d.  Design  and  code  anomalies  were  reported  during  the  coding  phase 
1 1>  1 :  -  -  >  . 

These  examples  indicate  that  even  in  highly  disciplined,  well-detined 
or  o  c; K  a  ms  .  anomalies  (errors)  always  occur. 
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